FIG. 1 illustrates some system aspects of a known proposal for arranging the communication connections between a mobile station 101 or 102 and a fixed packet-switched network. In FIG. 1 each mobile station or MS (or User Equipment or UE as in the UMTS specifications) is operating in a cellular telephone system of its own: UE 101 is a UMTS terminal operating in a UMTS network 103 and MS 102 is an enhanced GSM terminal operating in an enhanced GSM network 104. From both networks there is a connection to a GPRS network 105. The UMTS network 103 comprises a UTRAN or UMTS Terrestrial Radio Access Network 106 as well as a CN or Core Network 107. In the enhanced GSM network 104 a BSS or Base Station Subsystem 108 and an MSC or a Mobile Switching Centre 109 are shown. The detailed structure of the network elements is unessential to the present invention, but it is known that for example a UTRAN consists of a number of Radio Network Subsystems, each of which in turn comprises a Radio Network Controller and a number of Node Bs roughly corresponding to base stations. A BSS in turn comprises a Base Station Controller and a number of Base Transceiver Stations operating under it. Various mixed-mode cellular telephone systems are possible; for example the BSS 108 might operate under the same CN as the UTRAN 106. The mobile stations shown in FIG. 1 could also be exactly similar terminals operating close to each other in a single cell.
In FIG. 1 there is a connection both from the UTRAN 106 and from the BSS 108 to a corresponding SGSN or Serving GPRS Support Node 110 and 111. It is known to have a certain Packet Control Unit or PCU in the Base Station Subsystem and/or the UTRAN to act as a gateway to and from the SGSN. Both SGSNs 110 and 111 are in turn coupled, through the GPRS trunk lines, to a GGSN or Gateway GPRS Support Node 112 which may also have other functions: in FIG. 1 it is shown to operate as an MMSC or a Multimedia Messaging Service Center for the sake of example. The MSs may be coupled to different GGSN or they may be coupled to the same GGSN through the same SGSN; various communication configurations are available as is well known by the person skilled in the art.
Setting up an active communication connection between a terminal and the fixed packet-switched network, i.e. using a mobile station to access the packet data services offered through the fixed packet-switched network, means that a so-called PDP Context has to be activated between the mobile station and a GGSN. Activating PDP Contexts is known as such and proceeds through a known and documented exchange of messages between the mobile station and the GGSN. Specifically, the mobile station transmits an Activate PDP Context Request message in a way basically known as such. The BSS or UTRAN recognizes the Activate PDP Context Request message as concerning packet-switched services and consequently routes it to the current SGSN in a known way, e.g. through a PCU. After the SGSN has received the request a set of security functions may be executed between the mobile station and the SGSN. The SGSN validates the activation request and selects a GGSN based on the HLR (Home Location Register) records associated with the mobile station and/or an MS-provided APN (Access Point Name) string. The SGSN transmits to the selected GGSN a Create PDP Context Request message.
When the GGSN receives the message it checks, among others, the context type that the mobile station has requested. Known PDP types at the priority date of this patent application are IP for using Internet Protocol based services, X.25 for using X.25-protocol based services and OSP (Octet Stream Protocol) for using unstructured octet streams as the carrier for some otherwise unspecified services. The GGSN may select an external network element as the actual provider of the requested service, based on the APN and/or the PDP Configuration Options field in the context activation request. For some services also integrated with service provider the GGSN may act as the service provider. The GGSN creates an association with the service attributes and the established “tunnel” or PDP Context between it and the mobile station.
After the service has been activated and possibly some service-related parameters have been configured (e.g. according to the information delivered in the Protocol Configuration Options information element included in the activation request message in a known manner), the GGSN sends a Create PDP Context Response message to the SGSN, which receives it and transmits a corresponding Activate PDP Context Accept message to the MS. The reception of this message at the MS finalizes the context activation. After that, there is a logical tunnel in place between the MS and the GGSN.
The activation of the PDP Context may also take place upon the initiative of a service provider or other fixed network element. Such a procedure begins by a GGSN receiving a PDU or Protocol Data Unit which is noted to require the activation of a PDP Context. The GGSN may request a HLR or Home Location Register to provide valid routeing information for the mobile station concerned, which request the HLR answers with an acknowledging message containing the requested information, specifically the identifier (address) of the currently valid SGSN. The GGSN uses the received address to send a PDU Notification Request message to the SGSN, which answers with a PDU Notification Response message in order to acknowledge that it shall request the mobile station to activate the PDP Context indicated with a PDP Address received within the PDU Notification Request message. Thereafter the SGSN transmits a Request PDP Context Activation order to the mobile station through the appropriate radio access network. The mobile station should obey the order by commencing the procedure explained above as the mobile-originated PDP Context activation.
It is known that a mobile station may have several PDP Contexts active at any moment. There are no limitations to the Type attributes of these contexts, so there may even be several simultaneous active PDP Contexts of the same type.
The SGSNs and GGSNs collect charging information for each PDP Context separately. The problem of the known methods and arrangements for managing PDP Contexts is that there are no effective ways of associating a certain PDP Context with certain service or detailed service type in order for the network operator to arrange the charging according to actual usage of services.
There are naturally the known PDP Context Type attribute separately associated with each active PDP Context, as well as the QoS or Quality of Service profile which consists of certain service attributes and which could be indirectly used to indicate the service type. However, the known value space for PDP Context Type attributes is very limited and it is not feasible to extend it to cover a broad selection of possibly dynamically changing service alternatives. Using a QoS profile to characterize a service type is not reliable since there are no guarantees that such a “QoS profile->service type” mapping would be unambiguous: several different services or service types may require exactly same QoS profiled despite of them being clearly different from the charging point of view. The solution of using PDP addresses for identifying services is not feasible, because e.g. IP-based services are often associated with dynamically allocated IP addresses: it would be very difficult to maintain an up-to-date mapping table between dynamically allocated IP addresses and certain services. Static IP addresses are also not feasible due to the limited IP address space. In addition, some mobile stations may not be able to handle several IP-addresses simultaneously.